Protocols vs APIs

Protocols define how messages are traded. Application Programming Interfaces (APIs) define specific function calls a component will accept. Technologies such as CORBA, DCOM, XML-RPC, SOAP defines a way to map function calls of APIs to messages of certain protocols, providing remote access to APIs.

Designing a good protocol is much harder than defining an API. However, communication over remote APIs can often be far less efficient than communication over a well designed protocol.

The main reason why remote APIs can be inefficient is latency. Latency is the time it takes messages to cross the transport link used. A function call is typically mapped into two messages:

Sender Receiver Contents
Caller Callee Identity of function and argument values
Callee Caller Return value of the function call

The total amount of time spent on the remote function call is the total time spent on the following sequence of tasks:

  1. Constructing the function-call message.
  2. Transporting the function-call message to the Callee.
  3. Interpreting the function-call message.
  4. Executing the function call.
  5. Constructing the return-value message.
  6. Transporting the return-value message to the Caller.
  7. Interpreting the return-value message.

The execution of all these steps is known as a round-trip. The main efficiency problem with remote APIs is that each function call results in a round trip. Requesting four values using API calls results in four complete round trips.

./ff19883d1c13774bfe3e1396e608f346acaee71f.png

A custom protocol can improve on this by streaming request and responses independently.

./4ccb6dcc19162647e70f7d02600d619dc9dadc19.png

There is still just one communications channel, and both sides of the channel are still single threaded, but the latency becomes less significant.

Suggested reading

Somewhat related: